Choosing a metric changes what similarity means
Qdrant supports Dot product, Cosine similarity, Euclidean distance, and Manhattan distance for dense vector spaces. The metric determines how the index ranks vectors, so it must match the geometry expected by the embedding or representation model.
Cosine measures angular similarity and is common for text embeddings when vector direction matters more than magnitude. Dot product combines alignment with magnitude, so vector norm can affect ranking. Euclidean measures straight-line distance, while Manhattan measures the sum of absolute coordinate differences.
The trade-off is not simply speed. A metric can materially change retrieval semantics. I would normally follow the embedding model's training or retrieval guidance rather than picking a metric based on a generic rule such as 'text always means cosine.'
A version caveat is important: Qdrant's currently documented dense metrics include Manhattan, which was added in v1.7. Older deployments may not support it. Qdrant also supports sparse-vector search with different semantics, so dense-vector metric rules should not be generalized to every vector type.
Cosine focuses on vector direction
Dot product is affected by vector magnitude as well as alignment
Euclidean measures straight-line distance
Manhattan measures coordinate-wise absolute distance and is available in modern Qdrant versions
Two vectors point in the same direction but have very different lengths. Which metric would care more about that magnitude difference?
Your embedding provider recommends cosine similarity. Where would you configure that choice in Qdrant?
A migration from cosine to dot product changes the top search results. What would you check before blaming Qdrant?
Your model documentation does not clearly specify the intended similarity metric. How would you experimentally select one?
An embedding model's vector norms correlate strongly with document length, and dot-product search favors long documents. How would you decide whether that is desirable?
You need to support dense semantic search and sparse lexical retrieval in one system. How would the metric and search semantics differ?
You inherit several embedding models with different training objectives. How would you establish a platform-level policy for selecting and validating Qdrant metrics?
Offline evaluation shows cosine has better recall while dot product has better precision for a business-critical workload. How would you investigate the cause and make the production decision?